This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
The issue reported in the blog where the password of an id that is extracted never syncs up is working as designed. And if you think about it , it makes sense. You would not want to perform an audit by extracting the id and then having the extracted id sync with the id in the vault. This would change the password for the user and he/she would get locked out. The feature to extract the id is not intended to be used as a method to reset the password or solve those type of issues. The feature was created to allow audits. Therefore when you extract the id , set a password and perform the audit , you want to be able to do so without interfering with the user.
Another clarification. Id vault keeps tracks of the password history on the id. So in an environment where multiple copies of ids exist for a user that contain different password histories (very common prior to implementing id vault), then the sync process "breaks" (security reasons . we do not want to allow ANY id for a particular user to sync up).
I realize that this might be confusing, and hard to accept but once again if we put security ahead of everything else , it does make sense.
The scenario would be the following.
To give you an example let's say that we have 3 IDS on 3 different machines
ID #1 has had the following passwords
a) 1234
b)4567
c)8910
d)111213 current password
ID#2 was copied from the person document and a new password was set
a)4455
b)8910
c)111213 current password
ID#3 copy of ID#1 created after step A
a) 1234
b)111213 current password
In the example above we can see how all the ids have the same password currently but yet all of them have different password histories. Of course this is an extreme case but it is one that does occur frequently.
When id vault is then implemented one id will vault to the id vault. The one that gets there first will win over all the other ones. So in the example above if ID#3 happens to be the one that vaults first all other ids ID#2 and ID#1 will never sync.
We do this because we want to prevent , unauthorized copies and extractions of ids made from the admin or attackers to never impact the user.
When you run in situation where the ids do not sync up because of the password history, you can do the following
1. Delete all of the current ids on all of the machines
2. Reset the password on the id vault for the user
3. Have the user login on all 3 machines. this will download the id from the vault and it will ensure that all ids have the same password
Feedback response number RCAA9K5L68 created by ~Autumn Rejipyskioden on 05/15/2014